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1. Introduction 


This documentation gives important technical information about the 
GAL™ compiler program, CG. GAL™ is a C-based high-level language for the 
GAPP™ systolic array processor. Information in this document should be 
useful for users interested in working with the compiler outside the scope 
of the PC Development System. Normally the PC Development System calls 
the compiler program whenever a GAL™ source file needs to be compiled and 
takes care of all input files and flags to the compiler. Section 2 of this 
documentation provides information which will enable the user to call the 
compiler from the command shell of the UNIX™, PORS ER VENIX™/86, 
NCR-DOS, or MS™ -DOS penan system. 


Note: GAPP™ and GAL™ are trademarks of NCR Corporation. UNIX™ is a 
trademark of AT&T Bell Laboratories. VAX™ and VMS™ are trademarks of 
Digital Equipment Corporation. VENIX™ is a trademark of VenturCom Inc. 
MS™ is a trademark of Microsoft Corporation. NCR-DOS is NCR Corporation's 
version of MS-DOS. IBM@ is a registered trademark of International 
Business Machines Corporation. 


Many users may also wish to use the compiler program with a specific 
hardware configuration. Since CG is designed primarily for the PC 
Development System (GAPSYS) and the Simulator/Assembler (GAPSIM, 
GAPASM), other hardware configurations will require some interfacing 
work. This is usually done by interfacing the ASCII output of the compiler 
to a meta-assembler, which produces microcode for the hardware control 
store, or by writing a unique generator/interpreter which takes the 
intermediate output file of the compiler, and produces microcode. Section 3 
provides the details of the ASCI! output file, and section 5 provides the 
details of the intermediate output file. 


Note: All of the technical information contained in this document applies 
specifically to GAPSYS version 1.04, CG version 2.03, GAPSIM version LI, i 
and GAPASM version tl. It is the policy of NCR Corporation to improve 
products as new technology, components, software, and firmware become 
available. NCR Corporation, therefore, reserves the right to change 
specifications without prior notice. Contact NCR Microelectronics DSP 
Marketing, Ft. Collins, CO for information regarding versions other than 
those listed above. 
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2. Compiler Organization 


The program CG is a two-phase compiler, as shown in Figure 1. On the 
first phase, the input source files are parsed and checked for correct syntax 
and the intermediate output file is produced. On the second phase, the 
intermediate output file is read, and an output file is produced which 
contains the GAPP instructions and RAM addresses of the GAL program. GAL 
source files usually end with a .GAL extension (i.e. a program file with a 
filename such as ADD.GAL), although this is not strictly enforced, The 
intermediate output file will have the same filename with the extension 
changed to .SIF (t.e. the intermediate output file for the program ADD.GAL 
will be ADD.SIF). A complete program may be contained in more than one 
source file. Usually a programmer will write the main part of program in 
one file and place any subroutines in one or more library source files. 
During the second phase of the compiler, all the intermediate output files 
are linked together in memory before the final output file is generated. 
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Figure 1 Compiler Organization. 


The compiler is called from the command shell by the following 
command line: 


CG [-A [-X] ] [-B) [-T] [-S] {-L] [-N num] [-V] infiles [-O outfile] 


where anything in square brackets ([]) is optional; either upper or lower 
case may be used. The infiles are the filenames of the inputs to the 
compiler (more than one file may be compiled at a time). These files must 
either be GAL source files or intermediate output files: If the filename has 
a .SIF extension, it is assumed to be an intermediate output file, otherwise 
it is assumed to be a GAL source file. The dash options, such as -S and -L, 
are used to contro] the operation of the compiler and have the following 
meanings. 


-A The second phase of CG will produce an ASCII output file which 
contains the GAPP instruction mnemonics and RAM addresses for the 
GAL program (see section 3). This output file is suitable for use 
with the GAPP Simulator (GAPSIM) as a “do” file. If this option is 
not given, the second phase will produce a binary output file which 
is the same format as the output fite of the GAPP Assembler 
(GAPASM) (see section 4). If the -O option is also given, then the 
filename for the output file will be outfile. Otherwise, if the -A 
option is given the output filename will be OUT.G, and if the -A 
option is not given the output filename will be OUT.OBJ. 


Note: if the -A option is not given, the -B and ~X options are 
ignored. 


Controls the format of the RAM addresses in the output file 
produced by the -A option. When -X is given, the RAM addresses are 
printed as hexadecimal numbers (between O and IF). Otherwise they 
are printed as decimal numbers (between 0 and 127). 


Note: Both the -A and -X options are necessary when producing an 
output file to be used with the GAPP Simulator (GAPSIM) (see 
section 2.1) 


In a GAL source file, breakpoints may be included by using the 
program statement brkpoint. An example ts 


if (i == 6) brkpoint; 


which will produce a breakpoint when the int variable 1 is equal to 
6. Breakpoints are understood by the GAPP Simulator (GAPSIM). 
When this option is given, the Simulator command brkpoint will be 
placed in the ASCII output file. If this option is not given, any 
brkpoint statement in the GAL source code will cause an error 
message during the second phase of the compiler. 


Only the first phase of the compiler is run. Any infiles which are 
not intermediate output files are compiled and the corresponding 
SIF file is produced. 


Note: If the -S option is given the -A, -X, -B, -L, -T, -N, and -O 
options are ignored. 


Only the linking portion of the second phase of the compiler is run. 
All infiles which are not intermediate output files are compiled 
into .SIF files using the first phase of the compiler. Then all 
intermediate output files are linked together in memory. Instead of 
producing a final output file, however, another intermediate output 
file is produced which contains a linked version of all the 
intermediate output files. This linked intermediate output file is an 
exact copy of the intermediate output files linked together in 
memory which would normally be used to produce the final output 
file. If the -O option is also given, the filename for this output is 
outfile. Otherwise the filename ts OUT.LNK. 
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Note: Using the linked intermediate output file as one of the 
infiles in a later run of the compiler is discouraged. This option is 
provided mainly for the PC Development System. 


Note: if the -L option is given the -A, -B, -X, ~T, and -N options 
are ignored. 


-N As with any programming language, it is possible to get into an 
infinite loop. Since CG “unrolls” all loops, however, infinite loops 
can cause the second phase of the compiler to hang forever. To 
avoid the nasty possibilities this can imply,. after 10,000 GAPP 
instructions have been generated the user will be informed that 
there is a possible infinite loop, and will be asked whether to 
continue the compilation. The -N option changes the upper limit 
from 10,000 to num. 


-O The output filename is outfile. Otherwise the default output 
filename is used (OUT.G, OUT.OBJ, or OUT.LNK depending on the -A 
and -L options). 


Note: the following options are provided for use in-house by NCR and 
should have no importance to the user. They are documented here only to 
prevent confusion should they be accidently invoked by the user. 


-T Used by NCR in-house with the GAPP Tower Demonstration System. 
Automatically sets the -A option and appends a sequence of 
instructions necessary for correct operation on that system. 


-V Used by NCR in-house for debugging the compiler program. Turns on 
the “verbose” mode of the first phase. 


2.1 Using CG with the GAPP Simulator 


Figure 2 diagrams how the compiler CG is used to write GAL programs 
for the GAPP Simulator (GAPSIM). When writing GAL programs to be 
executed using GAPSIM, certain options must be given when producing the 
ASCII output file for use with the Simulator “do” command. Since all 
addresses in the “do” file must be in hexadecimal format, both the -A and -X 
options must be given when the second phase of the compiler is to be run. 
The Simulator understands the brkpoint command, and so the -B option may 
be used if breakpoints are included in the GAL program. 


GAL™ 






source CG GAPSIM 
files with -A and -x options “do” command 


(.GAL) 
ASCII Output File 


Figure 2 Using CG with the GAPP Simulator. 
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As an example, the files MAIN.GAL, ADD.GAL, AND MULTIPLY.GAL 
may be compiled and the ASCII output file MAIN.DO produced at the same 
time by the command 


CG -A -X -B MAIN.GAL ADD.GAL MULTIPLY.GAL -O MAIN.DO 


Alternatively, the program files may be compiled into intermediate output 
files with the command 


CG -5 MAIN.GAL ADD.GAL MULTIPLY.GAL 
and at a later time the ASCII output file may be produced by the command 
CG -A -X -B MAIN.SIF ADD.SIF MULTIPLY.SIF -O MAIN.DO 


The user should avoid writing GAL programs for the Simulator which 
make use of the GAPP Global Output, as this is not implemented in GAPSIM 
version 1.1, This means that the following types of GAL program 
statements should be avoided: 


if (gohigh) 
if (golow) 
while (gohigh) 
while (golow) 


2.2 Using CG with the PC Development System 


Figure 3 diagrams how the compiler CG is used by the PC Development 
System. Normally, the PC Development System will handle the interface to 
the GAL compiler in a way.that is transparent to the user. Understanding 
how this is done, however, allows the user to reduce the amount of time 
spent compiling GAL programs, and to perform some of the steps of the 
compilation outside the PC Development System if necessary. 
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Figure 3 Using CG with the PC Development System. 


The PC Development System only makes use of the first phase and the 
linking portion of the second phase of the compiler CG. The second phase of 
the compilation is done by a generator/interpreter written specifically for 
the PC Development System hardware board. This generator/interpreter is 
exactly the same as the generator/interpreter in the second phase of CG 
(see section 5) except that the GAPP Global Output is supported. Also, 
instead of writing GAPP instructions and RAM addresses to an output file, 
they are sent directly to the hardware board to be executed. 


When the user selects "C Compile GAL program" from the PC 
Development System main menu, the first phase of the compiler CG is run 
using the -S option and the filename specified by the user. When the user 
selects “D Debug GAL program” from the main menu, the program file 
which the user specifies and all program files in the library list are 
compiled. Both compiler phases will be run on any program files which have 
been edited with the "P Program Edit" option, since they were last 
compiled. Only the second phase will be run on any program files which have 
not been edited since they were last compiled. The -L option is used to 
produce a linked intermediate output file, which can then be used by the PC 
Development System's own generator/ interpreter. 


As an example, assume that the user is working with a file called 
MAIN.GAL, and has library subroutines in the files ADD.GAL and 
MULTIPLY.GAL. Also assume that MAIN.GAL and ADD.GAL have been 
recently edited. If the user selects "C Compile GAL program” from the 
main menu and gives the filename MAIN.GAL, the compiler is run using the 
command 


CG -S MAIN.GAL 


if the user selects the "D Debug GAL program” option from the main menu 
and gives the filename MAIN.GAL, the compiler is run using the command 


CG -L MAIN.GAL ADD.GAL MULTIPLY.SIF -0 MAIN.LNK 


When the user is making changes to more than one GAL program file at 
a time, it is recommended that the "D Debug GAL program’ option be used 
from the main menu instead of the °C Compile GAL program’ option, This 
will reduce the amount of time associated with the startup of the program 
CG by having all the edited program files compiled at the same time. 


3. ASCI! Output File Format 


The ASCII output file produced by the compiler CG has one GAPP 
instruction and RAM address, or one Simulator command per line, written as 
ASCII text. The GAPP instruction and RAM address follows the following 
format: the first part of the line may be one or more tabs or spaces, which 
is called white space. The RAM address is written next as a one, two, or 
three digit decimal number between O and 127. Finally the mnemonics for 
the RAM, C register, EW register, NS register, and CM register instruction 
fields are written in that order, separated by white space. Each mnemonic 
is written in the form 


destination:=source 


where destination is the destination of the mnemonic and may be ram, c, 
ew, ns, or cm, and source is the source of the mnemonic and may be ram, 
c, ns, ew, cm, sm, cy, bw, 0, 1, e, w, n, s, or cms (note that not all 

combinations are valid instructions - see the NCR45CG72 data sheet for 
details). If any instruction field is zero, indicating a NOP, then the 
mnemonic for that field is not printed. 


As an example, the following GAPP instructions are a portion of an 
ASCI! output. In this case, the section of code performs the addition of 
unsigned magnitude values in two image variables. 


ns:=ram c:=0 
ew:=ram 
ram:-=sm c:-cy 
ns:=ram 
ew:=ram 
ram:=sm c:=cy 
ns:=ram 
ew:=ram 
ram:=sm C:=cy 
ram:=c 


Di 


OSAN N AH AWS 


The only Simulator command which is included in the ASCII output 
file is the brkpoint command, which is printed with no leading white 
space, and nothing else printed on the line. 


4. Binary Output File Format 


The binary output file produced by the compiler CG has each GAPP 
instruction and RAM address written in binary format as shown in Figure 4. 
Fach instruction and address form a pair, where the instruction is written 
first as a word and the address is written next as a byte. This pattern 
continues until the the last pair, after which an “End of File" signal will be 
seen. The sizes for words and bytes on each of the machines for which CG is 
supported are given in Table 1. On each machine, the word size is larger 
than the number of bits occupied by the GAPP instruction, so only the 13 
least significant bits of the instruction are valid, and the other bits may 
contain any values. Likewise, only the 7 least significant bits of the 
address are valid. 


Instruction 1 
Address |1 
A Instruction 2 


Address 2 





fa Valid instruction or address bits 





Figure 4 Binary Output File Format. 


VAX / VMS 8 32 
VAX / UNIX (4.2 BSD) 8 32 
NCR Tower / UNIX 8 32 
NCR PC4, PC4i, PC6, PC8 / NCR-DOS 8 l 16 
IBM@ PC, PC-XT, PC-AT, | 

and compatibles / MS-DOS 8 16 
NCR PC4, PC4i, PC6, PC8 / VENIX 8 16 
{BM@ PC, PC-XT, PC-AT 

and compatibles / VENIX 8 16 


Table 1 Byte and Word Sizes (Number of Bits) for Supported 
Machines. 


5 The Generator/!interpreter Model 


The second phase of the compiler takes the intermediate output file 
as input interprets it, and generates GAPP instructions and RAM addresses 
as output (either in ASCII or binary format). Any user who wishes to do the 
same for a specific hardware configuration should create a 
generator/ interpreter which follows the same basic construction as the 
second phase of the compiler CG. 


The generator/interpreter can be thought of as a simple type of 
processor which accepts the data in the intermediate output file, executes 
it as if it were a program, and produces GAPP instructions and RAM 
addresses as output. Such a processor has three distinct memory 
structures, a set of internal registers, and a set of opcodes. 


5.1 The Memory Structures 

Each of the three memory structures in the generator/interpreter 
model is a set of memory locations, each of which is the size of one word. 
Each memory location holds a two's complement value, therefore each 
memory location can hold a value from - 20-1 to 207} - 1, where n is the 
number of bits in a word. Table 1 gives the word size for each machine for 
which the compiler CG is supported. These memory locations are addressed 
by internal registers (see section 5.2), each of which Is also the size of one 
word. Therefore the memory locations in each memory structure have 
addresses from 0 to 2" - 1. 


The three memory structures are as follows: 


1. The Code memory structure holds the set of intermediate output file 
opcodes which are to be interpreted by the generator/ interpreter. 


2. The Variable memory structure holds the set of data which are the 
int variables of the GAL program. Each variable is assigned a 
Variable memory address number, and the variable names in the 
source file are replaced by Variable memory addresses in the 
intermediate output file. The same address may correspond to more 
than one variable, since variables only exist within the pair of 
brackets ({}) in which they are declared. In addition, some variables 
(global, and extern) are assigned absolute Variable addresses, 
while others (auto) are assigned addresses which are relative to the 
contents of the Auto Pointer internal register (see section 5.2). 


3. The Stack memory structure is where most of the actual processing 
takes place. Certain intermediate output file opcodes transfer values 
from the Variable memory and piace them on top of the Stack 
memory, which is defined by the contents of the Stack Pointer 
internal register (see section 5.2). Other opcodes operate upon the 

topmost contents of the Stack memory, and others transfer data 
from the Stack memory back to the Variable memory. 


Depending upon implementation tradeoffs, there may be other memory 
structures, such as link tables and symbol tables, in addition to the three 
listed above. These are completely user dependent, however, and the — 
generator/interpreter model makes no assumptions about these. | 


5.2 The Internal Registers , 


Each of the five internal registers is made up of the same number of 
bits as a word of one of the three memory structures. Each is used to hold 
information which must be retained over more than one intermediate output 
file opcode. Depending upon implementation tradeoffs, there may be other 
"registers" (or software variables which count as registers) which hold 
important information. However, the following set of internal registers is 
sufficient to hold all information needed by the generator/interpreter, and 
no assumptions are made about any others. 


1. The Program Counter register holds the value of the Code memory 
address which contains the next intermediate output file opcode to be 
interpreted. Each time anew opcode is to be interpreted, the opcode 
is fetched from the memory location specified by the Program 
Counter. Then the Program Counter is incremented to the next 
Code address. 


2. The Stack Pointer register holds the address of the Stack memory 
which is currently defined as the top of the Stack Stack addresses 
greater than the value of the Stack Pointer do not hold valid data. 


Note: The following internal registers hold information which ts used 
within a subroutine. Each time a subroutine is called, the registers 
are initialized as described in section 5.3. When the subroutine is 
exited, the old values of the registers are retrieved. This allows GAL 
subroutines to be reentrant. A subroutine may call a copy of itself, 
and all auto variables in the second subroutine will be independent 
from those in the first. 


3. The Argument Pointer register holds the address of the otack 
memory that is the beginning of the arguments which were passed to 
the subroutine. i 


4 The Auto Pointer register holds the address of the Variable 
~ memory which is the beginning of the address space available to the 
subroutine for auto int variables. The subroutine may use all 
addresses, beginning with the address tn this register, through the 
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end of the Variable memory structure. 


5. The Address Pointer register holds the address of the GAPP RAM 
which is the beginning of the address space available to the 
subroutine for auto image variables. The subroutine may use all 
addresses, beginning with the address in this register, through the 
end of the GAPP RAM address space (address 127). 


5.3 Use of the Memories and Registers 


At the beginning of the interpretation of the intermediate output file 
opcodes in the Code memory, the Variable and Stack memories are 
initialized as follows. The beginning of the Variable memory holds the 
values to which the global and extern variables have been initialized. 
These values occupy Variable address O through n - 1, where n is the 
number of global and extern data values (this number is contained in the 
intermediate output file header, see section 6.1). The Auto Pointer 
register is set to n, so that all Variable memory addresses from n through 
the end of the Variable memory are available for auto int variables in the 
main program and any subroutines that it calls. 


Similarly, the number of GAPP RAM addresses occupied by global 
image variables is stored in the Address Pointer register. All GAPP RAM 
addresses from the contents of the Address Pointer register through 127 
are available for auto image variables in the main program and’ any 
subroutines that it calls. 


The Stack Pointer and Argument Pointer registers are both set to 
zero. The main program has no arguments, and the top of the Stack at the 
beginning of the main program is the very beginning of the Stack memory. 


When a subroutine is called, the arguments to the subroutine are first 
pushed onto the Stack (see section 5.4.1), followed by the number of 
arguments. The value of the Argument Pointer register in the calling 
routine is then pushed onto the stack, so that the calling routine will not 
lose the information about where its own arguments are stored. 


Note: Whenever an image variable name is passed to a subroutine, two 
values are actually pushed onto the stack as subroutine arguments. The 
first is the starting address of the image variable, and the second is the 
number of bits in the image variable (the size). 


values vs. mnemonics (this would be useful as part of a header file for a 
generator/interpreter). Any opcode value not listed is either reserved for 
future use, or else is reserved to preserve compatibility with older versions 
of the compiler which use opcodes that have been obsoleted. The following 
Sections describe the function of each opcode. 


Mnemonic: Value: Mnemonic: Value: Mnemonic: Value: 


ADDRARG 559 ADDRAUTO 037 BLOCKEND 926 
BLOCKSTART 940 « BRKPNT 061 CALL 902 
CONDEND 028 ENTRY 094 GAPPADDR 930 
GAPPINST 529 GETARG 996 GETAUTO 941 
GETGLOB 942 JMP 231 JMPEQ 052 
JMPGOHI 933 JMPGOLOW 534 LINK 049 
OPBINMIN 506 OPBITAND 518 OPBITNOT 504 
OPBITOR 920 OPBITXOR 919 OPCONST 001 
OPDIY 008 OPEQ ol6 OPGT 913 
OPGTEQ 519 OPLOGAND 921 OPLOGNOT 003 
OPLOGOR 922 OPLT 312 OPLTEQ 9514 
oP MOD 009 OPMULT 207 OPNOTEQ O17 
OPPLUS 909 OPSHL 510 OP SHR oll 
OPUNMIN 902 POPSTK 936 PROGEND 098 
PUTARG 557 PUTAUTO 943 PUTGLOB 544 
RESUME 999 RETURN 9935 REYSTK 939 
START 960 STATEND 929 


Table 2 Intermediate Output File Opcode Values. 


5.4.1 Main Program and Subroutine Opcodes 


The following opcodes are used to implement the main routine and 
subroutine calling procedures discussed in section 23. 


CALL - Subroutine call. The arguments and the number of argument 
values have already been pushed onto the Stack by previous opcodes. 
The Code address of the first opcode of the subroutine is on the top 
of the stack, the amount to increment the Auto Pointer register is 
the next value down on the stack, and the amount to increment the 
Address Pointer is the second value down from the top of the 
Stack. 


ENTRY - Subroutine entry point. This is the first opcode interpreted in a 


subroutine. The value in the Stack Pointer is copied into the 
_ Argument Pointer register. 
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PROGEND - Program end. This is the opcode used to indicate that the 
end of the main program has been reached. Interpretation of the 
intermediate output file halts. 


START - Program start. This is the first opcode of the main program. 
The initialization of the Variable memory and internal registers 
mentioned in section 5.3 is assumed to have been done by the same 
initialization routines that loaded the opcodes into the Code memory 
(see section 5.3), Any additional initialization or startup functions 
are performed when this opcode is encountered. 


RESUME - Calling program resume. The amount to decrement the Auto 
Pointer register is on the top of the Stack. The amount to 
decrement the Address Pointer register is the next value down on 
the Stack. The second value from the top of the Stack is the return 
value from the subroutine. The structure of the Stack below this is 
described in section 5.3. 


RETURN - Subroutine return. The return value is on the top of the 
Stack. The return value is popped off the Stack and written into the 
empty placeholder, the address of which is the value of the 
Argument Pointer minus 2. The value of the Argument Pointer is 
copied into the Stack Pointer register, and the return Code address 
is popped off the new “top” of the Stack into the Program Counter 
register. 


5.4.2 Read/Write Opcodes 


The following opcodes are used to read a data value from the 
Variable or Stack memory, or write a data value from the top of stack into 
the Variable or Stack memory structure. 


GETARG - The data value to be read is one of the arguments to the 
subroutine, and is located in the Stack memory. The argument offset 
of the data value to be read is on the top of the Stack, where O is the 
offset of the first argument pushed onto the Stack during the 
subroutine call. The number of arguments on the Stack is read from 
the Stack memory, the argument offset is popped off of the Stack, 
and the data value to be retrieved is read from the Stack memory and 
pushed onto the Stack. The address of the number of arguments Is 
the value of the Argument Pointer register minus 4, and the 

- address of the value to be read is the value of the Argument Pointer 
register minus 4, minus the number of arguments, plus the argument 
offset. 
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PUTARG - A data value is to be written into one of the arguments to the 


subroutine, which is located in the Stack memory. The argument 
offset to be written is on the top of the Stack, where O is the offset 


of the first argument pushed onto the Stack during the subroutine 
call. The value to be written is the next value down on the stack. The 
number of arguments on the Stack is read from the Stack memory, 
the argument offset is popped off of the Stack, and the data value to 
be written is read from the top of the Stack (but not popped) and 
written into the Stack memory address of the argument. The address 
of the number of arguments is the value of the Argument Pointer 
register minus 4, and the address of the argument to be written is the 
value of the Argument Pointer register minus 4, minus the number 
of arguments, plus the argument offset. 


GETAUTO - The data value to be read is an auto int variable, and is 
located in the Variable memory. The offset of the variable is on the 
top of the Stack. The address of the variable is the value of the 
Auto Pointer register plus the offset. The offset is popped off of 
the Stack, and the data value is read and pushed onto the Stack. 


PUTAUTO - The data value is to be written into an auto int variable 
which is located in the Variable memory. The offset of the variable 
is on the top of the Stack, and the data value to be written is the 
next value down on the Stack. The address of the variable is the value 
of the Auto Pointer register plus the offset. The offset is popped 
off of the Stack, and the data value is read from the top of the Stack 
(but not popped) and written into the Variable memory address of 
the variable. 


GETGLOB - The data value to be read is a global int or extern int 
variable and is located at the beginning of the Variable memory. The 
absolute address of the variable is on the top of the Stack. The 
address is popped off of the Stack, and the data value is read from 
the Variable memory address and pushed onto the Stack. 


PUTGLOB - The data value is to be written into a global int or extern 
int variable, which is located at the beginning of the Variable 
memory. The absolute address of the variable is on the top of the 
Stack, and the value to be written is the next value down on the 
Stack. The address is popped off of the Stack, and the data value Is 

. read from the top of the Stack (but not popped) and written into the 
Variable memory address. 


5.4.3 Stack Control Opcodes 


The following opcodes are used to control the operation of the Stack 
memory structure. “Pushing” a data value onto the top of the Stack means 
that the Stack Pointer register is incremented by one and the data value is 
written into the Stack at the new address in the Stack Pointer. “Popping” 
a data value off of the top of the Stack means that the data value is read 
off the Stack memory address in the Stack Pointer, and the Stack 
Pointer register is then decremented by one. 


OPCONST - A data value is pushed onto the top of the Stack. The new 
data value is read from the Code memory address in the Program 
Counter register and the Program Counter is incremented by one. 


REVSTK - The data value on the top of the Stack and the next data value 
down on the Stack are exchanged. 


DOPSTK - The data value on the top of the Stack is popped off of the 
Stack. 


5.4.4 Operator Opcodes 


The following opcodes perform arithmetic, boolean, and logical 
operations on data values which are on the top of the Stack memory. Those 
operations which take two data values as operands pop two values off the 
top of the Stack, and push the result onto the top of the Stack. Those 
operations which take only one data value as an operand pop a value off the 
top of the Stack and push the result onto the top of the Stack. In the 
explanations below, the first operand is the data value on the top of the 
Stack, and the second operand is the next data value down on the Stack. 


OPBINMIN - The result is the second operand minus the first operand. 


OPBITAND - The result is the bitwise AND of the first and second 
operands. 


OPBITNOT - The result is the bitwise inversion of the first operand. 
OPBITOR - The result is the bitwise OR of the first and second operands. 


OPBITXOR - The result is the bitwise exclusive OR of the first and 
second operands. 
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OPDIV - The result is the second operand divided by the first operand. 


OPEQ - The result is a non-zero value if the first and second operands 
are equal. Otherwise, the result is zero. 


OPGT - The result is a non-zero value if the second operand is greater 
than the first operand. Otherwise the result is zero. 


OPGTEQ - The result is à non-zero value if the second operand is greater 
than or equal to the first operand. Otherwise the result is zero. 


OPLOGAND - The result is a non-zero value if the first and second 
operands are both non-zero. Otherwise the result is zero. 


OPLOGNOT - The result is a non-zero value if the first operand is 
non-zero, Otherwise the result is zero. ' 


OPLOGOR - The result is a non-zero value if either the first operand or 
the second operand are non-zero. Otherwise the result is zero. 


OPLT - The result is a non-zero value if the second operand is less than 
the first operand. Otherwise the result is zero. 


OPLTEQ - The result is a non-zero value if the second operand is less 
than or equal to the first operand. Otherwise the result is zero. 


OPMOD - The result is the remainder of the second operand divided by 
the first operand. 


OPMULT - The result is the multiplication of the first and second 
operands. Note that the result is the same size (number of bits) as 
the two operands. 


OPNOTEQ - The result is a non-zero value if the first and second 
operands are not equal. Otherwise the result is zero. 


OPPLUS - The result is the addition of the first and second operands. 


OPSHL - The result is the second operand shifted ieft by the number of 

bit positions given in the first operand. Bits shifted out of the most 

- significant bit position are lost. Bits shifted into the least 
significant bit position are zero. 


OPSHR - The result is the second operand shifted right by the number of 
bit positions given in the first operand. Bits shifted into the most 
significant bit position may be either the same as the previous most 
significant bit (for arithmetic fill) or zero (for logical fill). Bits 
shifted out of the least significant bit position are lost. 


OPUNMIN - The result is the arithmetic negative of the first operand. 


5.4.5 GAPP Interface Opcodes 


The following opcodes are used to generate GAPP instructions and 
RAM addresses. 


ADDRARG - The value on the top of the Stack is the argument offset of 
an image variable, which is to be converted to the starting GAPP RAM 
address of the image variable. The number of arguments on the 
Stack is read from the Stack memory, the argument offset is 
popped off of the Stack, and the starting address is read from the 
Stack memory and pushed onto the Stack. The address of the number 
of arguments is the value of the Argument Pointer register minus 
4, and the address of the value to be read is the value of the 
Argument Pointer register minus 4, minus the number of 
arguments, plus the argument offset. 


Note: The ADDRARG opcode functions exactly the same as the 
GETARG opcode and will be removed from future versions of CG. 


ADDRAUTO - The value on the top of the Stack is the offset of an auto 
image variable, which is to be converted to the starting GAPP RAM 
address of the image variable. The offset is popped off of the Stack, 
and the starting address is pushed onto the Stack. The starting 
address is the offset plus the value of the Address Pointer register. 


GAPPADDR - The value on the top of the Stack is the RAM address for 
the next GAPP instruction. The address is popped off of the Stack, 
and saved until the next GAPPINST opcode is encountered, at which 
time the address and instruction are written to the output file. 


GAPPINST - The value on the top of the Stack is a GAPP instruction. 


The instruction is popped off of the Stack, and is written to the 
` output file, along with the address from the last GAPPADDR opcode. 
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5.4.6 Jump Opcodes 


The following opcodes are used for program flow control. 


JMP - The value on the top of the Stack is the Code address of the next 
opcode to be interpreted. The address is popped off of the Stack, and 
written into the Program Counter register. 


JMPEQ - The value on the top of the Stack is the Code address of the 
next opcode to be intérpreted if the next value down on the Stack is 
zero, The address and the value are popped off of the stack, and if the 
value is zero the address is written into the Program Counter 
register. Otherwise, the Program Counter js left unchanged. 


JMPGOHI - The value on the top of the Stack is the Code address of the 
next opcode to be interpreted if the GAPP Global Output pin is high. 
The address is popped off of the Stack, and the status of the Global 
Output is checked, If the Global Output is high, the address is written 
into the Program Counter register, otherwise the Program 
Counter is left unchanged. 


JMPGOLOW - The value on the top of the Stack is the Code address of 
the next opcode to be interpreted if the GAPP Global Output pin is low. 
The address is popped off of the Stack, and the status of the Global 
Output is checked. If the Global Output is low, the address is written 
into the Program Counter register, otherwise the Program 
Counter is left unchanged. 


Note: The JMPGOHI and JMPGOLOW opcodes are supported by the 
generator/interpreter which is part of the PC Development System, but 
will cause an error if they are encountered by the generator/ interpreter 
in the second phase of the compiler CG. 


5.4.7 The Link Opcode 


Because a GAL program can be distributed across several files, it is 
not possible to resolve all references to variables and subroutines during 
the first phase of the compiler. Therefore, a method of postponing the 
reference is used, which makes use of the LINK opcode. The LINK opcode is 
not a true opcode, since it is intercepted by the linking part of the second 
phase and replaced with an OPCONST opcode (see section 5.4.3). The LINK 
opcode is followed by ten words in the intermediate output file, which are 
replaced by a single word which becomes the value associated with the 
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OPCONST opcode. The first word following the LINK opcode is the offset, 
the second word is the label number, and the last eight words are a symbol 
name, with one character of the symbol name per word (in ASCII format). 
Each of the three entries following the LINK opcode (the offset, the label 
number, and the symbol name) are translated into a value, all of which are 
added together to obtain the final value associated with the OPCONST 
opcode. ‘ 


The offset value is added directly into the final value. 


if the label number is 4 or greater, then the value associate with that 
label number is read from the label table in the intermediate output file 
(see section 6.4) and added into the final value. Label numbers O through 3 
have special meaning as described below. 


O Ignore the label number entry. Add nothing into the final value. 


1 Translate this label number into a value equal to the amount of 
Variable memory space taken up by intermediate output files 
already linked together. This is the sum of the inittalization 
data count entry in the intermediate output file headers (see 
section 6.1). If this is the only intermediate output file being 
linked, or is the first file in the list of files being linked, then the 
value will be zero. Add this value into the final value. 


2 Translate this label number into a value equal to the starting 
address of the image variable given in the symbol name entry. The 
symbol tables of each of the intermediate output files being linked 
are examined until the symbol name is found (see section 6.2). Then 
the starting address entry is read and added into the final value. 


3 Translate this label number into a value equal to the size (number 
of bits) of the image variable given in the symbol name entry. The 
symbol tables of each of the intermediate output files being linked 
are examined until the symbol name is found (see section 6.2). Then 
the size entry is read and added into the final value. 


If the first word of the symbol name entry is zero, then the entry ts 
ignored and nothing is added into the final value. Otherwise, the symbol 
tables of each of the intermediate output files being linked are examined 
until the symbol name is found (see section 6.2). Then the offset of the 
symbol is read and added into the final value (unless the label entry is 2 or 
3, in which case the starting address entry or size entry is used). 
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5.4.8 Directory Opcodes 


The following opcodes are provided so that a generator/interpreter 
may have information about what portion of a GAL source file is currently 
being processed. This may be useful for debugging and optimization, 

BLOCKEND - The previous opcode was the last opcode of a block in the 

GAL source code. A block is composed of any GAL program statements 
enclosed in brackets ({}). The compiler assigns a unique block number 
to each block for the purposes of debugging, and the number of the 
block which surrounds the block just exited is in the next Code 
address. If this is the outermost block of a main routine or 
subroutine, then the surrounding block number will be zero. 


BLOCKSTART - The next opcode is the first opcode of a new block in the 
GAL source code. A block is composed of any GAL program statements 
enclosed in brackets ({}). The compiler CG assigns a unique block 
number to each block for the puporses of debugging, and the number of 
the new block follows in the next Code address. 


Note: The generator/interpreter in the PC Development system uses 
the BLOCKEND and BLOCKSTART opcodes to keep track of which 
variables are active (auto variables are only active inside the block 
in which they are declared, while global and extern variables are 
always active). Any active image variable may be uploaded using the 
“Upload RAM" option in the Debug menu. 


BRKPOINT - This opcode indicates that a brkpoint statement appeared 
in the GAL source code at this point. 


Note: The generator/interpreter in the compiler CG will produce the 
Simulator command brkpoint whenever the BRKPOINT opcode is 
encountered. The generator/interpreter in the PC Development 
System will suspend interpretation of the intermediate output file 
whenever the BRKPOINT opcode is encountered. The user may use any 
of the commands in the Debug menu, and may resume interpretation of 
the intermediate output file by using the "G GAPP instr’, “B 
Breakpoint”, or “F Finish program” options in the Debug menu. 


CONDEND - The previous opcode was the end of a complex conditional 
© statement. The conditional statement may be composed of more than 
one statement (each of which is marked by a STATEND opcode), and 
even one or more blocks (marked by BLOCKSTART and BLOCKEND 
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opcodes). 


STATEND - The previous opcode was the end of a GAL program 
Statement. 


6. The Intermediate Output File Format 


The intermediate output file contains binary information produced by 
the first phase of the compiler program CG. The file contains not only the 
opcodes interpreted by the generator/interpreter, but also contains 
information about variable and subroutine names (tne symbol table), 
initialization information (the initialization data table), and information 
about labels used for subroutine calls and jump destinations (the label 
table). Each of these tables is found in the intermediate output file in the 
order in which they are discussed below. Also discussed is how each table 
of the linked intermediate output file, which results from linking several 
intermediate files together, is obtained. 


6.1 The File Header 


The file header serves as a directory of the rest of the information in 
the intermediate output file, and also holds important: information for the 
linker. The header is made up of several entries, each of which takes up one 
word in the file (see Table 1), and which are arranged in the order in which 
they are discussed below. 


symbol table count ~ contains the number of entries in the symbol 
table of the intermediate output file. Each symbol table entry is 
made up of eight bytes followed by seven words (see section 6.2), 


label table count - contains the number of entries in the label table. 
Each label table entry is made up of two words (see section 6.4). 


initialization data count - contains the number of entries tn the 
initialization data table (see section 6.3), Each inittalization data 
table entry is made up of one word. Since each initialization data 
entry is written into one Variable memory address, the 
initialization data count is also the number of Variable memory 

_ addresses used by this file for global int and extern int variables. 
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actual code count - contains the actual number of entries in the code 
table. Each entry in the code table consists of one word, and is either 
an opcode to be loaded into the Code memory, a value associated with 
an OPCONST opcode (see section 5.4.3), or part of a list of ten values 
associated with a LINK opcode (see section 5.4.7). 


linked code count - contains the number of entries in the code table 
minus nine entries for every LINK opcode in the code table. This is 
the number of Code memory addresses which will be used by the 
intermediate output file after the LINK opcodes have all been 
converted to OPCONST opcodes by the linker. 


absolute RAM count - contains the number of GAPP RAM addresses 
used by global image and extern image variables which are 
declared using the absolute declaration form. The absolute 
declaration form is 


image name: start_address: end_address; 


Since no relatively declared image variables are allowed to occupy 
space dedicated to a absolutely declared image variable, the absolute 
RAM count entry is the maximum of the end_address of all 
absolutely declared image variables in a GAL source file. 


relative RAM count - contains the number of GAPP RAM addresses used 
by global image and extern image variables which are declared 
using the relative declaration form. The relative declaration form 1S 


image name: number_bits; 


block count - contains the number of blocks used by this intermediate 
output file (see section 5.4.8), 


label number - contains the number of the highest label used by this 
intermediate output file, plus one. Note that because not all label 
numbers are used, this entry is not the same as the label table count. 


executable flag - set to one if this intermediate output file contains 
the main routine, zero otherwise. 


executable offset - if the executable flag is one, contains the 
offset within the code table where the main routine begins. Note that 
this offset counts all LINK opcodes and associated values as two 
entries (i.e. this offset is valid only after the LINK opcodes have been 
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resolved into OPCONST opcodes). 


Each entry of the linked header is obtained by summing the 
corresponding entries from the header of each intermediate output file 
being linked. The only exceptions are the absolute RAM count, the 
executable flag, and the executable offset entries. 


The absolute RAM count entry of the linked header is the maximum 
of the absolute RAM count entries of all the intermediate output files 
being linked. 


The executable flag entry of the linked header ts set to one if any 
of the intermediate output files being linked have the executable flag 
entry set to one. It is an error for more than one intermediate output file to 
have the executable flag set to one. The executable offset entry is set 
when the intermediate output file which has the executable flag set to 
one is encountered and is left alone at all other times. When this file is 
encountered, the executable offset entry of the linked file is set to the 
executable offset entry of the file plus the sum of the actual code count 
entries of all intermediate output files linked prior to this file. Thus the 
executable offset is the actual offset of the main routine within the 
linked code table (see section 6.5). 


6.2 The Symbol Table 


The symbol table contains information about all image and int 
variable names, and all subroutine names used in the GAL program source 
file. The table is made up of the number of entries given in the symbol table 
count entry of the file header. Each symbol table entry consists of eight 
bytes and seven words (see Table 1), and is composed of the following 
entries, arranged in the order in which they are discussed. 


symbol name - consists of eight bytes, which is the first eight 
characters of the name of the variable or subroutine. The first byte 
of the entry is the first character of the name, the second byte is the 
second character, etc. 


Note: All of the remaining symbol entries consist of one word each. 


type - indicates the meaning of a value assigned to a variable or the 
meaning of the value the subroutine returns. Each of the following 
entry values has the meaning described below. Any other type entry 
value is illegal, 
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0 
1 
2 


int variable or subroutine returning an int value. 
absolutely declared image variable. 


relatively declared image variable. 


Note: See section 6.1 for absolute and relative declaration forms. 


class - indicates where the variable is stored, or where the subroutine 
is located. Each of the following entry values has the meaning 
described below. Any other class entry value is illegal. 


0 


AWD 


auto variable (i.e. declared locally in the main routine or in a 
subroutine). 

global variable or subroutine. 

variable which is an argument to a subroutine. 

extern variable or subroutine. 

undefined variable or subroutine. This class code is only used 
internally by the compiler and should not be seen in an 
intermediate output file. 


function flag - set to one if the symbol belongs to a subroutine. The 
flag is zero otherwise. If this flag is set to one, the type entry must 
be 1, and the class entry must be | or 3. 


offset - only valid for symbols with type entry 1, and class entry O, |, 
or 2, or for symbols with type entry 2 or 3, and class entry 2. Its 
meaning depends on the type and class entry values. Each of the 
following type and class entry values results in a meaning for the 
offset entry as described below. The offset entry is undefined for 
any other type and class entry values. 


type 1, class: 


0 


The offset entry is the offset within the main routine’s or 
subroutine’s space for auto int variables in the Variable 
memory. This is the offset value used with the GETAUTO and 
PUT AUTO opcodes (see section 5.4.2). 


If the function flag entry is not set to one, the offset entry is 
the absolute Variable memory address of the int variable. This 
is the offset value used with the GETGLOB and PUTGLOB opcodes 
(see section 5.4.2). If the function flag entry is set to one, the 
offset entry is the offset within the code table of the beginning 
of the subroutine. 
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2 The offset entry is the argument number of the int subroutine 
argument. This is the offset value used with the GETARG and 
PUTARG opcodes (see section 5.4.2). 


type 2 or 3, class: 


2 The offset entry is the argument number of the starting address 
of the image subroutine argument. Recall that an image variable 
name as a subroutine argument actually results in two subroutine 
arguments pushed onto the Stack (see section 5.3). This is the 
offset value used with the ADDRARG opcode (see section 5.4.5). 


Starting address - only valid for symbols with type entry 2 or 3, and 
its meaning depends on the class entry. Each of the following class 
entry values results in a meaning for the starting address entry as 
described below. The starting address entry is undefined for any 
other class entry value. 


O The starting address entry is the starting address offset 
within the main routine’s or subroutine’s auto image space in 
the GAPP RAM. This is the offset used with the ADDRAUTO 
opcode (see section 5.4.5). 


1 The starting address entry is the absolute GAPP RAM starting 
address of the global image variable. This the offset used with 
the GAPPADDR opcode (see section 3.4.5). 


size - only valid for symbols with type entry 2 or 3. This entry gives 
the number of bits which the image variable is declared to have. 


block number - gives the unique block number assigned by the compiler 
in which this variable or subroutine was declared (see section 5.4.8). 
If the the symbol has class entry 1, then the block number entry 
will be zero. 


As each intermediate output file is linked, the symbols from its 
symbol table are installed into the linked symbol table. Symbols which nave 
class | (global) are checked to see that they do not conflict with any other 
global symbols. Symbols already in the linked symbol table which have 
class 3 (extern) or 4 (undefined) may be replaced by global symbols with 
the same name as they are encountered. At the end of the linking procedure, 
it is an error for any extern or undefined symbols to be left in the linked 
symbol table. i 
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As part of the installation procedure, the entries of the symbol table 
in the intermediate output file are modified before inotallation into the 


linked symbol table. As an example, consider a symbol which has type entry 
O (int) and class entry 1 (global). This variable is to be stored in a 
Variable memory address, the value of which is held in its offset entry. 
However, there may be (and probably are) other global int variables with 
the same offset entry value in other intermediate output files, so the 
offset entry of the symbo] must be modified in order not to conflict with 
other variables. This is a case of a shared resource, parts of which must be 
allocated to each intermediate output file. A complete list of the shared 
resources, the associated entry, and the action taken to modify the entry is 
given below, 


Code memory addresses: 
For all symbols which have class | (global), type O (int), and the 
function flag set to one, the offset entry is increased by the sum 
of the linked code count header entries of all previously linked 
intermediate output files. 


Variable memory addresses: 
For all symbols which have class | (global), type O (int), and the 
function flag not set to one, the offset entry is increased by the 
sum of the initialization data count header entries of all 
previously linked intermediate output files. 


GAPP RAM addresses: 
For all symbols which have class | (global), and type 2 (relatively 
declared image) the starting address entry is increased by the sum 
of the relative RAM count header entries of all previously linked 
intermediate output files. 


Note: relatively declared global image variables are not allowed to 
conflict with (i.e. share the same GAPP RAM addresses with) 
absolutely declared global image variables. However, there is no 
way to know how much GAPP RAM space is taken up by absolutely 
declared global image variables until all intermediate files have 
been linked. Rather than making a second pass through the symbol 
table to modify all starting address entries for relatively declared 
global image variables, there is a convention that all references to 
the starting address of a relatively declared global image variable 
= shall be through the use of a LINK opcode, using the special label 
value 2 (see section 5.4.7). This way the starting address entries 
are modified when the LINK is resolved after the symbol table is 
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installed (see section 6.5), 


Note: It may seem intuitive that the starting address entries of 
absolutely declared global image variables should also be modified. 
However, these image variables are allowed to conflict (with other 
absolutely declared image variables only), and so no partitioning of 
the resource is needed. i 


Compiler-assigned unique block numbers: 
Two blocks from different source files should not have the same 
block number in the linked file. For all symbols which do not have 
class | (global), 3 (extern), or 4 (undefined) the block number 
entry is increased by the sum of the block count header entries of 
all the previously linked intermediate output files. 


6.3 The Initialization Data Table 


The initialization data table contains data which is to be loaded into 
Variable memory addresses prior to interpretation of the intermediate 
output file. The number of entries is given in the initialization data 
count header entry, and each entry takes one word. The first entry is to be 
loaded into Variable memory address zero, the second is to be loaded into 
address one, etc. However, since the Variable memory addresses are 
shared resources (see section 6.2), the addresses into which the data is lo 
be loaded must be increased by the sum of the initialization data count 
header entries of all previously linked intermediate output files. 


6.4 The Label Table 


The label table records the matchings between values and the label 
numbers used with LINK opcodes. The nurnber of entries is given in the 
label table count header entry, and each entry takes two words. The first 
word of the entry is the label number, and the second word is the associated 
value. 


The label numbers, like the other items discussed in section 6.2, are a 
shared resource. Therefore, as the labels from an intermediate output file 
are being installed into the linked label table, the label number of each 
entry is increased by the sum of the label number header entries of the 
previously linked intermediate output files. 
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6.5 The Code Table 


The code table holds the opcodes and LINK entries of the intermediate 
output file. The number of entries in the code table is given in the actual 
code count header entry, and each entry consists of one word. After 
removal of the LINK opcodes and associated values, the number of entries 
will be the value in the linked code count header entry. 


There is a complication involving the removal of LINK opcodes. The 
information from the symbol tables of all the intermediate output files 
being linked is needed to ensure that all LINK entries can be resolved. To 
accomplish this, the linking procedure is done in two phases. On the first 
phase, the header, symbol table, label table, and initialization data table are 
linked from each intermediate output file, and the code table is skipped 
over. On the second phase, the header is re-linked (to ensure the 
availability of the same information about the sum of header entries of 
previously linked intermediate output files), the label table, symbol table, 
and initialization data table are all skipped over, and the code table is 
linked. 


The entries in the code table are to be loaded into the Code memory, 
with the first entry in the table being loaded into Code memory address 
zero, the next entry loaded into address one, etc. The Code memory 
addresses, as discussed in section 6.2, are a shared resource. Therefore, 
before each code table entry of an intermediate output file is loaded into 
Code memory, the Code memory destination address is increased by the 
sum of the linked code count header entries of the previously linked 
intermediate output files. 


As part of the linking procedure, most opcodes encountered from the 
code table are simply loaded directly into the Code memory. Certain 
opcodes are intercepted, however, and cause special action to be taken. 


OPCONST - The OPCONST opcode is loaded directly into Code memory. 
However, the value following the opcode in the code table may be any 
value, including the same value as an intercepted opcode. This value 
is loaded directly into Code memory following the opcode without 
any interception. 


LINK - An OPCONST opcode is loaded into Code memory. The next ten 
values from the code table are translated into a single value (see 
section 5.4.7), which is loaded into Code memory following the 
opcode. 
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